خرید و فروش ارز دیجیتالی

user story چیست ؟ یا داستان کاربر، توصیف های کوتاه و ساده ای از یک ویژگی هستند که از دیدگاه شخصی که تصمیم به توسعه یک اپلیکیشن یا وب سایت دارد، معمولا یک کاربر یا مشتری سیستم گفته می شود. آنها معمولا از یک الگوی ساده پیروی می کنند:

در توسعه نرم افزار و مدیریت محصول، User story یک توصیف غیررسمی و به زبان ساده از یک یا چند ویژگی یک سیستم نرم افزاری است. یک User story، نوع کاربر، آنچه را که می خواهد و اینکه چرا می خواهد را توصیف می کند. User story یک نیاز را با یک توضیح ساده بیان می کند. بسته به پروژه، User story ها ممکن است توسط ذینفعان مختلفی مانند مشتریان، کاربران، مدیران یا اعضای تیم توسعه نوشته شود.
همچنین می توانید مطالب قسمت User flow را نیز مطالعه کنید.

معمولا جزئیات به دو روش به User story اضافه می شوند:

• با تقسیم User story کلی به چندین User story کوچکتر
• با افزودن شرایط رضایت بخش
  

  
  چه کسی User story را می نویسد؟

  هر کسی می تواند داستان های کاربری بنویسد مخصوصا گرافیست ها. این مسئولیت مالک محصول است که اطمینان حاصل کند که یک حجم از داستان‌های کاربری برای هر محصول وجود دارد، اما این بدان معنا نیست که مالک محصول کسی است که آنها را می‌نویسد. در طول یک پروژه خوب، باید نمونه هایی از داستانهای کاربری توسط هر یک از اعضای تیم نوشته شده باشد.

  همچنین توجه داشته باشید که مهمتر از اینکه چه کسی User story را می نویسد، کسی است که در بحث های مربوط به آن شرکت می کند. یعنی کاربران و مشتریانی که نظرات و کامنت های خود را به اشتراک می گذارند.

  Ures story چه زمانی نوشته می شود؟

  User story در سراسر پروژه نوشته می شود. معمولا کارگاه پروژه نویسی نزدیک به شروع پروژه چابک (Agile) نوشته می شود. همه اعضای تیم با هدف ایجاد یک بک لاگ برای محصول شروع می کنند که به طور کامل عملکرد هایی را که باید در طول پروژه یا یک چرخه 3 تا 6 ماهه در آن اضافه می شود، توضیح دهد. به علاوه، داستان های جدید را می توان در هر زمان و توسط هر کسی نوشت و بک لاگ محصول اضافه کرد.

  User Stories – INVEST

  مخفف INVEST مجموعه ای از معیارها یا چک لیست های پذیرفته شده برای ارزیابی کیفیت داستان کاربر کمک می کند. اگر داستا نتواند این معیارها را برآورده کند، تیم باید آن را بازنویسی کند (که اغلب به معنای دوراندازی داستان قبلی و نوشتن یک داستان جدید است.)

  یک داستان کاربر خوب باید این باشد – INVEST:

  • مستقل: باید خودکفا باشد به نحوی که اجازه دهد بدون وابستگی به یکدیگر آزاد شوند.
  • قابل مذاکره: فقط ذات نیاز کاربر را به تصویر بکشید و فضایی برای گفتگو باقی بگذارید. داستان کاربر نباید مانند قرارداد نوشته شود.
  • ارزشمند: ارزش را به کاربر نهایی ارائه می دهد.
  • قابل تخمین: داستان های کاربر باید بتوانند تخمین زده شوند تا بتوان به درستی اولویت بندی کرد و در اسپرینت ها قرار گرفت.
  • کوچک: یک داستان کاربر یک تکه کوچک از کار است که اجازه می دهد آن را در حدود 3 تا 4 روز کامل کنید.
  • قابل آزمایش: یک داستان کاربر باید از طریق معیارهای پذیرش از قبل نوشته شده تأیید شود.

  ریشه های داستان های کاربر

  اولین بار در کتاب کنت بک “برنامه نویسی افراطی توضیح داده شده” ذکر شده است. این متن بدون ساختار بود که کاملاً شبیه موارد استفاده با محدودیت در اندازه بود.

  ران جفریس مفاهیم 3C را معرفی کرد: کارت، مکالمه، تایید در سال 2001.

  2003: چک لیست INVEST برای ارزیابی سریع داستان های کاربر در مقاله ای نوشته شده توسط بیل ویک منشأ می گیرد که همچنین نام اختصاری SMART (خاص، قابل اندازه گیری، دست یافتنی، مرتبط، با زمان بندی) را برای وظایف ناشی از تجزیه فنی داستان های کاربر تغییر داده است.

  2004: مخفف INVEST یکی از تکنیک‌هایی است که در «داستان‌های کاربری کاربردی» مایک کوهن توصیه می‌شود.

user story چیست ؟ یا داستان کاربر، توصیف های کوتاه و ساده ای از یک ویژگی هستند که از دیدگاه شخصی که تصمیم به توسعه یک اپلیکیشن یا وب سایت دارد، معمولا یک کاربر یا مشتری سیستم گفته می شود. آنها معمولا از یک الگوی ساده پیروی می کنند:

در توسعه نرم افزار و مدیریت محصول، User story یک توصیف غیررسمی و به زبان ساده از یک یا چند ویژگی یک سیستم نرم افزاری است. یک User story، نوع کاربر، آنچه را که می خواهد و اینکه چرا می خواهد را توصیف می کند. User story یک نیاز را با یک توضیح ساده بیان می کند. بسته به پروژه، User story ها ممکن است توسط ذینفعان مختلفی مانند مشتریان، کاربران، مدیران یا اعضای تیم توسعه نوشته شود.
همچنین می توانید مطالب قسمت User flow را نیز مطالعه کنید.

معمولا جزئیات به دو روش به User story اضافه می شوند:

• با تقسیم User story کلی به چندین User story کوچکتر
• با افزودن شرایط رضایت بخش
  

  
  چه کسی User story را می نویسد؟

  هر کسی می تواند داستان های کاربری بنویسد مخصوصا گرافیست ها. این مسئولیت مالک محصول است که اطمینان حاصل کند که یک حجم از داستان‌های کاربری برای هر محصول وجود دارد، اما این بدان معنا نیست که مالک محصول کسی است که آنها را می‌نویسد. در طول یک پروژه خوب، باید نمونه هایی از داستانهای کاربری توسط هر یک از اعضای تیم نوشته شده باشد.

  همچنین توجه داشته باشید که مهمتر از اینکه چه کسی User story را می نویسد، کسی است که در بحث های مربوط به آن شرکت می کند. یعنی کاربران و مشتریانی که نظرات و کامنت های خود را به اشتراک می گذارند.

  Ures story چه زمانی نوشته می شود؟

  User story در سراسر پروژه نوشته می شود. معمولا کارگاه پروژه نویسی نزدیک به شروع پروژه چابک (Agile) نوشته می شود. همه اعضای تیم با هدف ایجاد یک بک لاگ برای محصول شروع می کنند که به طور کامل عملکرد هایی را که باید در طول پروژه یا یک چرخه 3 تا 6 ماهه در آن اضافه می شود، توضیح دهد. به علاوه، داستان های جدید را می توان در هر زمان و توسط هر کسی نوشت و بک لاگ محصول اضافه کرد.

  User Stories – INVEST

  مخفف INVEST مجموعه ای از معیارها یا چک لیست های پذیرفته شده برای ارزیابی کیفیت داستان کاربر کمک می کند. اگر داستا نتواند این معیارها را برآورده کند، تیم باید آن را بازنویسی کند (که اغلب به معنای دوراندازی داستان قبلی و نوشتن یک داستان جدید است.)

  یک داستان کاربر خوب باید این باشد – INVEST:

  • مستقل: باید خودکفا باشد به نحوی که اجازه دهد بدون وابستگی به یکدیگر آزاد شوند.
  • قابل مذاکره: فقط ذات نیاز کاربر را به تصویر بکشید و فضایی برای گفتگو باقی بگذارید. داستان کاربر نباید مانند قرارداد نوشته شود.
  • ارزشمند: ارزش را به کاربر نهایی ارائه می دهد.
  • قابل تخمین: داستان های کاربر باید بتوانند تخمین زده شوند تا بتوان به درستی اولویت بندی کرد و در اسپرینت ها قرار گرفت.
  • کوچک: یک داستان کاربر یک تکه کوچک از کار است که اجازه می دهد آن را در حدود 3 تا 4 روز کامل کنید.
  • قابل آزمایش: یک داستان کاربر باید از طریق معیارهای پذیرش از قبل نوشته شده تأیید شود.

  ریشه های داستان های کاربر

  اولین بار در کتاب کنت بک “برنامه نویسی افراطی توضیح داده شده” ذکر شده است. این متن بدون ساختار بود که کاملاً شبیه موارد استفاده با محدودیت در اندازه بود.

  ران جفریس مفاهیم 3C را معرفی کرد: کارت، مکالمه، تایید در سال 2001.

  2003: چک لیست INVEST برای ارزیابی سریع داستان های کاربر در مقاله ای نوشته شده توسط بیل ویک منشأ می گیرد که همچنین نام اختصاری SMART (خاص، قابل اندازه گیری، دست یافتنی، مرتبط، با زمان بندی) را برای وظایف ناشی از تجزیه فنی داستان های کاربر تغییر داده است.

  2004: مخفف INVEST یکی از تکنیک‌هایی است که در «داستان‌های کاربری کاربردی» مایک کوهن توصیه می‌شود.